One of a variety of services for which information relating to a quality of this service might have to be transmitted is a streaming class service.
For a streaming class service, a streaming server sends media data via a network to a streaming client such that the media data can be processed at the client side as a steady and continuous stream. An example for a streaming application is an Internet video product. The streaming server can also reside within the network.
Operators of the network or service providers have an interest in being able to evaluate the Quality of Service (QoS) perceived by the user of a streaming client. Currently, a streaming session as defined using the protocols standardized in 3GPP TS 26.234 offers the possibility to know a limited amount of information about the perceived end user quality. Real-Time Transport Control Protocol (RTCP) Receiver Reports are transmitted by the client to the server for reporting information on the network behavior, for instance information about packet losses, delay jitter, cumulative highest sequence number received and other information about Real-Time Transport Protocol (RTP) packets. In addition, RTCP Sender Reports are transmitted by the server to the client, which contain information about the sender.
However, these reports do not enable a streaming server, or the operator through a streaming server, to obtain any additional information about the perceived QoS from the streaming client, e.g., about the number of corrupted video frames, the duration of rebufferings, the duration of audio gaps, etc. Such information can be conveyed from a streaming client to a streaming server only by extending the current information carried by Real-time Transport Control Protocol (RTCP) reports, RTCP eXtended Reports or RTCP XR packets. Such an extension comprises a set of QoS metrics including information about session set-up and teardown, speech and audio gaps, corrupted video frames, rebuffering and initial buffering, packets lost in a succession and possible other information about session and media transmission.
The IETF RFC 2328 (RTSP specification, April 1998), the IETF RFC 3550 (RTP specification, July 2003) and the draft RTP Control Protocol Extended Reports (RTCP XR, May 2003), for example, enable a streaming client to report information on the received RTP packets, including packet loss fraction, delay jitter, highest sequence number received and sequence of packet losses.
The two documents Draft Rel-6 “PSS Quality Metrics Permanent Document”, 3GPP TSG-S4 Meeting #27, Jul. 7-11 2003, Tdoc S4-030562 and in “Stream Quality Metrics—Client metrics”, 3GPP TSG-S4 Meeting #26, May 5-9 2003, Tdoc S4-030353 describe additional general issues of QoS metrics in 3GPP (3rd Generation Partnership Project). The first document describes what information should be sent using 25 different parameters for speech, audio, video, player and network metrics, and what kind of protocol should be used. In addition, the second document defines high-level requirements and technical considerations. The documents define a method where the client calculates the information and sends it to the server when requested. For transport purposes, it is proposed to use a Real-Time Streaming Protocol (RTSP) GET_PARAMETER message sent from the server to the client, and an RTSP SET_PARAMETER message sent from the client to the server.
These messages are defined in more detail in the document “Streaming quality Metrics—Transport”, 3GPP TSG-S4 Meeting #28, 1-5 Sep. 2003, Tdoc S4-030629. It is proposed that an RTSP SET_PARAMETER message is transmitted from the server to the client for triggering the QoS metrics. The client can respond with an RTSP 200 OK message if it accepts to send QoS metrics. The server can then send a description of the QoS metrics session with a further SET_PARAMETER message including a metrics session description METRICS-SETUP, which contains a Range, Period and Sender parameter. Also this message has to be accepted by the client with an RTSP 200 OK message. Alternatively, the server can ask the client to provide a description of the QoS metrics session with a GET_PARAMETER message. Once the QoS metrics session is described and agreed upon, either a client can send the QoS metrics with a SET_PARAMETER message, or the server can retrieve the QoS metrics with a GET_PARAMETER message.
It is a disadvantage of this approach that the three pairs of required messages cause a delay, which may slow down the session setup. The proposed approach may even mix up the setup, since the client may already be sending the first message to acquire the data from the server before receiving the second SET_PARAMETER message.